自分たちのAWS環境のセキュリティアセスメントをしてみよう – NIST CSF適合パック活用例

こんにちは、臼田です。

みなさん、自分たちのAWS環境のセキュリティチェックしていますか？(挨拶

今回はタイトル通り、「自分たちのAWS環境のセキュリティアセスメントをしてみよう」というテーマで書いてみます。

直近触ったNIST CSFのConformance Packsを利用すると、幅広いAWS上のセキュリティについてチェックすることができるため、このチェック項目を細かく解説していくことで、AWSセキュリティについての理解を深めていけるのではないかと考えて、作ってみました。

前置き

NIST CSFやConformance Packsとはなんぞや？というところは下記で説明しています。今回のきっかけの記事でもあります。

簡単に説明すると、NIST CSFはグローバルスタンダードになりつつあるサイバーセキュリティのフレームワークで、Conformance PacksはNIST CSFを始めとするコンプライアンスチェックを実施できる仕組みです。

NIST CSFのConformance Packsテンプレートには45個のルールがあるため、これらの項目の背景と、どう考えて対応していけばいいかを細かく解説したら、自分たちのAWS環境のセキュリティについて考えを深めることができると思ったのでまとめます。

チェック項目の解説

項目自体は下記から引用しています。設定方法などは下記を確認してください。

設定をして結果を眺めてみてもいいですし、設定しなくても下記の解説を読んで自分たちの環境ではどうしていきたいかを考えてもいいでしょう。

それでは解説していきます。

それぞれのチェック項目の脅威や背景を説明し、そのチェック項目をどのように活用したらいいかや、代替手段の提示などをしてみます。個人的見解が入っていることはご了承ください。

• AccessKeysRotated
  • アクティブなアクセスキーが maxAccessKeyAge で指定された日数内にローテーションされているかどうかをチェックします。maxAccessKeyAgeで指定された日数以上、アクセスキーがローテートされていない場合、このルールは違反となる。
  • アクセスキーのローテートは、一般的なパスワードの定期更新に近い意味合いがあります。
  • 実際にはアクセスキーの利用には大きく2種類あり、ユーザーが利用する場合と外部サービスやオンプレミスサーバーが利用する場合があります
  • ユーザー利用の場合にはパスワードと同じような意味合いですが、これはやりすぎると煩雑になるデメリットがあります
  • しかし一般的なパスワードの定期更新によるデメリットである、パスワードが使い回しになりやすい、単調になりやすいということは、アクセスキーにはありません(自動生成のため)
  • MFAを利用して保護することもできるため、必ずしも必要ではないことが多いと思います
  • 外部サービスで利用する場合には極力IAM Roleを利用すべきです。IAMユーザーのアクセスキーを使うべきではありません。
  • もし外部サービスがIAM Roleを利用する機能がなければ、改善要望を出したほうがいいでしょう。
  • オンプレミスサーバーからのアクセスキー利用の場合には送信元IPを絞るなどの対策もあるため、ローテートだけに依存しない対策も可能だと思います。
• AcmCertificateExpirationCheck
  • アカウント内の ACM 証明書が指定された日数内に期限切れとなっているかどうかをチェックします。ACM が提供する証明書は自動的に更新されます。ACMは、インポートした証明書を自動的に更新しません。
  • 証明書切れはWebサイトがうまく利用できなくなる典型的な要因の一つです。
  • 数年に1度のものであるため運用上忘れられがちです。
  • 基本的にはこのチェック項目を活用するといいでしょう。
  • 加えてACMで発行した証明書であればDNS検証で自動更新が可能です。
  • なるべく自動更新の活用が望ましいです。
• CloudTrailCloudWatchLogsEnabled
  • AWS CloudTrailのトレイルがAmazon CloudWatchのログにログを送信するように設定されているかどうかをチェックします。トレイルのCloudWatchLogsLogGroupArnプロパティが空の場合、トレイルは非準拠となります。
  • まずCloudTrailのログを出力する先はS3とCloudWatch Logsの2つがあります。
  • 基本的にログ永続化のためにS3保存は必須です。
  • CloudWatch Logsはリアルタイム性と検索性などが優れている反面コストは高いので、まずは利用用途があるか確認しましょう。
  • Logsに出すのであれば、フィルターを活用して様々な異常に迅速に対応できるようにしましょう。
  • CISベンチマークでは有用なフィルターを定義しているためこちらを参考に設定するのもいいでしょう。
• CloudTrailEnabled
  • AWSアカウントでAWS CloudTrailが有効になっているかどうかをチェックします。
  • 基本的なサービスですべてのアカウントで有効化が必須です。
  • これがないと何もトラッキングできません。
• CloudTrailEncryptionEnabled
  • AWS CloudTrailがサーバーサイド暗号化（SSE）AWS Key Management Service（AWS KMS）カスタマーマスターキー（CMK）暗号化を使用するように設定されているかどうかをチェックします。KmsKeyIdが定義されていればルールに準拠しています。
  • SSEは透過的に暗号化してくれる非常に楽な機能のため、活用すること自体は悪くありません。
  • 暗号化されたデータへアクセスするためには保存されているS3へのアクセス権とは別に、KMSの権限も必要になります。ただこの場合の権限管理はやや煩雑になるため、どこを主軸に管理するかなどは事前に定義したほうがいいでしょう。
• CloudwatchLogGroupEncrypted
  • Amazon CloudWatch Logsのロググループが暗号化されているかどうかをチェックします。CloudWatch Logsのロググループが暗号化されていない場合、このルールはNON\_COMPLIANTになります。
  • ロググループの暗号化は上記と同じ問題があります。
• Ec2InstanceManagedBySsm
  • アカウント内のAmazon EC2インスタンスがAWS Systems Managerで管理されているかどうかを確認します。
  • AWS Systems Manager(SSM)は非常に便利なEC2管理機能です。
  • EC2に含まれるインベントリ情報(パッケージのバージョン等)を収集したり、パッチを適用するPatch Manager、SSHのポートを開けずにシェルアクセスできるSession Managerなど様々あります。
  • 基本的に便利なため活用していくべきです。
  • しかしながら上述したSession Managerは不必要なOS上へのアクセスを許可してしまうことがあるため、機能についてよく理解してから活用しましょう。
• Ec2InstanceNoPublicIp
  • Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにパブリック IP アソシエーションがあるかどうかをチェックします。Amazon EC2インスタンスの構成項目にpublicIpフィールドが存在する場合、このルールはNON\_COMPLIANTです。このルールはIPv4にのみ適用されます。
  • 基本的にWebサーバーなどはプライベートなサブネットに設置し、パブリックにはALBのみ露出させるような構成を取るためEC2にパブリックIPが必要な機会は少ないです。
  • SSHの踏み台サーバーを建てる場合もありますが、上述したSSMのSession Managerを利用できるとこれもなくすことができるためよりセキュアになります。
  • それができる場合、このルールを活用するといいでしょう。
• Ec2ManagedinstanceAssociationComplianceStatusCheck
  • インスタンス上でのアソシエーション実行後、AWS Systems ManagerのアソシエーションのコンプライアンスステータスがCOMPLIANTかNON\_COMPLIANTかをチェックします。フィールドステータスがCOMPLIANTの場合、ルールはコンプライアントになります。
  • SSMのステートマネージャーという機能でアソシエーションできているかを確認する項目です。
  • ステートマネージャーでは共通化されたサーバー内部のセットアップやドメインへの参加、パッチ適用のポリシーなどのドキュメントを実行できます。
  • これは適用するドキュメントをどのようなものにするかで大きく変わってくる項目です。
  • セットアップなどのオペレーションをSSMに任せることにより、共通化・自動化を図ることもできるでしょう。
  • しかしながらSSMのドキュメントの作成や維持管理はやや大変ですので、検討している場合には実際に作成を試みてから、どうするか考えるといいでしょう。
• Ec2SecurityGroupAttachedToEni
  • デフォルト以外のセキュリティグループが Amazon Elastic Compute Cloud (EC2) インスタンスまたはエラスティックネットワークインターフェース (ENI) にアタッチされているかどうかをチェックします。このルールは、セキュリティグループがEC2インスタンスやENIに関連付けられていない場合、NON\_COMPLIANTを返す。
  • EC2にセキュリティグループがアタッチされていない場合、そのEC2にアクセスできない状態です。
  • 一般的にはそのような状況はあまり発生しないためこのルールはそのまま活用するといいでしょう。
• EfsEncryptedCheck
  • Amazon EFSがAWS KMSを使用してファイルデータを暗号化するように設定されているかどうかをチェックします。DescribeFileSystemsで暗号化キーがFalseに設定されているか、DescribeFileSystemsのKmsKeyIdキーがKmsKeyIdパラメータと一致しない場合、このルールはNON\_COMPLIANTになります。
  • 前述したストレージの暗号化と同じ問題です。
• ElasticsearchEncryptedAtRest
  • Amazon Elasticsearch Service (Amazon ES) ドメインで、残りの部分の設定で暗号化が有効になっているかどうかをチェックします。EncryptionAtRestOptionsフィールドが有効になっていない場合、ルールはNON\_COMPLIANTとなります。
  • 前述したストレージの暗号化と同じ問題です。
  • ちなみにElasticSearch Serviceはパブリックからのアクセスを許可することも可能なため、そちらもよく確認が必要です。
• ElbAcmCertificateRequired
  • このルールは、Elastic Load BalancerがAWS Certificate Managerが提供するSSL証明書を使用しているかどうかをチェックします。このルールを使用するには、Elastic Load BalancerでSSLまたはHTTPSリスナーを使用する必要があります。
  • 昨今の事情を鑑みるとHTTPSでの提供は必須でしょう。
  • 幸いにもAWS環境では無料の証明書を簡単に発行して適用できるため、積極的にこれを利用しましょう。
  • 逆に通信が保護されていないHTTPでのサービス提供はよくありません。
• EmrMasterNoPublicIp
  • Amazon Elastic MapReduce (EMR) クラスターのマスターノードがパブリック IP を持っているかどうかをチェックします。マスターノードにパブリックIPがある場合、ルールはNON\_COMPLIANTとなります。
  • パブリックIPをもたせる必要性がほぼないサービスです。気をつけましょう。
• EncryptedVolumes
  • アタッチ状態のEBSボリュームが暗号化されているかどうかをチェックします。
  • 前述したストレージの暗号化と同じ問題です。
  • EBSは一律でデフォルト暗号化有効が可能なので積極的に活用しましょう。
• IamGroupHasUsersCheck
  • IAMグループに少なくとも1人のIAMユーザがいるかどうかをチェックします。
  • 使われていないグループは削除しましょう。
• IamPasswordPolicy
  • IAMユーザーのアカウントパスワードポリシーが指定された要件を満たしているかどうかをチェックします。
  • パスワードポリシーが準拠されているかは非常に重要な項目です。
  • 合わせてパスワードポリシー自体も見直しましょう。
  • また、多数のAWSアカウントでIAMユーザーを発行している場合、一つのAWSアカウントに集約するか、SAML等を利用してIDを集約しましょう。
  • 多数のパスワード管理はユーザーを疲弊させます。
  • AWS間のユーザー移動はIAM RoleでSwitch Roleするやり方が一般的です。
• IamPolicyNoStatementsWithAdminAccess
  • デフォルトバージョンのAWS Identity and Access Management (IAM)ポリシーに管理者アクセス権がないかどうかをチェックします。いずれかのステートメントに "Effect "がある場合 "アクション "で "許可" "Resource "の上に "**"がある場合 "**"の場合、そのルールは非準拠となります。
  • ユーザーが誤ってAdministratorAccessと同じようなポリシーを設定したことを検知できます。
  • そのようなことが起きる前に、まずAWSマネージドポリシーの活用や、ポリシー設計の方針、だれがポリシーを作成できるのかを決めることが必要でしょう。
  • 少なくともこのような設定をしてしまう習熟度のユーザーにポリシーを作成させることはあまり好ましく有りません。
  • IAMの権限管理のパターンはIAMの薄い本がとても参考になります。
• IamRootAccessKeyCheck
  • ルートユーザーのアクセスキーが利用可能かどうかをチェックします。ユーザーアクセスキーが存在しない場合はルールに準拠します。
  • ルートユーザーのアクセスキーが必要な場面はありません。リスクにしかならないため削除しましょう。
• IamUserGroupMembershipCheck
  • IAMユーザーが少なくとも1つのIAMグループのメンバーであるかどうかをチェックします。
  • 基本的に権限をユーザーにつけることは好ましくなく、グループを利用して権限管理をするといいです。
  • ただ、ケースバイケースなところはあると思います。
• IamUserMfaEnabled
  • AWS Identity and Access Managementのユーザーが多要素認証(MFA)を有効にしているかどうかをチェックします。
  • MFAは必須です。すべてのユーザーに義務付けましょう。
• IamUserNoPoliciesCheck
  • IAM ユーザーにポリシーが添付されていないことをチェックします。IAMユーザーは、IAMグループまたはロールから権限を継承する必要があります。
  • ポリシーを直接ユーザーにアタッチするべきではありません。
• IamUserUnusedCredentialsCheck
  • AWS Identity and Access Management (IAM)のユーザーが、指定した日数内に使用されていないパスワードまたはアクティブなアクセスキーを持っているかどうかをチェックします。
  • 利用されないものは削除しましょう。
  • ごくたまにしか使わないのであれば、必要ないのではないでしょうか？別の手段も検討しましょう。
• IncomingSshDisabled
  • 使用中のセキュリティグループが無制限の SSH トラフィックの着信を許可していないかどうかをチェックします。
  • SSHを全開放することはかなり良くないです。
  • 前述したSSM Session Manager等を活用してSSH自体を行わないことも検討しましょう。
  • Session Managerではシェルの履歴をS3に保存することもでき、SSHで通常残せない証跡を残せるメリットもあります。
• InternetGatewayAuthorizedVpcOnly
  • インターネットゲートウェイ（IGW）が認可されたAmazon Virtual Private Cloud（VPC）にのみ接続されているかどうかをチェックします。IGWが認可されたVPCに接続されていない場合、ルールはNON\_COMPLIANTになります。
  • IGWがすべてのVPCに必要なわけではないでしょう。
  • しかし必要なVPCも多いためこれは難しい課題です。
  • トランジットゲートウェイやVPC Peeringを駆使してインターネットへの経路をAWS全体で管理するような場合にはこのようなルールが活躍すると思います。
  • しかしこのような構成は単一障害点を生みやすく、クラウドの利便性が下がる傾向にあります。
  • トラフィックを集めて管理する思想はオンプレミスに近いものであるので、それが必ずしも必要ではないのではないか、というところから考えましょう。
• LambdaFunctionPublicAccessProhibited
  • Lambda関数ポリシーがパブリックアクセスを禁止しているかどうかをチェックします。
  • Lambdaがパブリックに直接利用できる必要性はないでしょう。
• MfaEnabledForIamConsoleAccess
  • コンソールパスワードを使用するすべてのAWS Identity and Access Management (IAM)ユーザーに対してAWS Multi-Factor Authentication (MFA)が有効になっているかどうかをチェックします。MFAが有効になっている場合、ルールは準拠しています。
  • 例外なく必須です。
• RdsInstancePublicAccessCheck
  • Amazon Relational Database Service (RDS) インスタンスがパブリックアクセスできないかどうかをチェックします。インスタンス設定項目のpublicAccessibleフィールドがtrueの場合、ルールは非準拠です。
  • 例外なく必須です。
• RdsSnapshotsPublicProhibited
  • Amazon Relational Database Service (Amazon RDS) スナップショットが公開されているかどうかをチェックします。既存および新規のAmazon RDSスナップショットが公開されている場合、このルールは非準拠です。
  • 例外なく必須です。
• RdsStorageEncrypted
  • RDS DB インスタンスでストレージの暗号化が有効になっているかどうかをチェックします。
  • 前述したストレージ暗号化の問題と同じです。
• RedshiftClusterPublicAccessCheck
  • Amazon Redshift クラスターがパブリックアクセスできないかどうかをチェックします。クラスタ構成項目のpublicAccessibleフィールドがtrueの場合、ルールはNON\_COMPLIANTとなります。
  • 例外なく必須です。
• RestrictedIncomingTraffic
  • 使用中のセキュリティグループが、指定したポートへの無制限の着信TCPトラフィックを許可しないようになっているかどうかをチェックします。
  • 追加で指定したポートについて0.0.0.0/0からのアクセス許可がされているかを確認できます。
  • SSHに限らず0.0.0.0/0からのアクセスを許可するケースはパブリック公開しているWebサービスのようなものでなければほぼ無いはずです。
  • 間違ってもFTPやSMBなどを公開することはやめましょう。
  • 必ず別の手段を検討しましょう。
  • メールサーバーを立てているケースもたまに見かけますが、SESなどのサービスを利用しましょう。
  • 多くのケースでAWS環境上でDNSやメールサーバーなどを動かす必要性は無いはずです。
• RootAccountHardwareMfaEnabled
  • AWSアカウントで多要素認証(MFA)ハードウェアデバイスを使用してルート認証でサインインすることが有効になっているかどうかをチェックします。
  • ハードウェアMFAは仮想MFAよりも、より所持による認証が厳密に可能になりますが、デバイス自体がボトルネックになります。
  • 復旧手段はありますが簡単ではないため、その運用をよく検討する必要があるでしょう。
  • 一方仮想MFAはどのツールを使うかでリスクが変わり、特にクラウドサービスを利用する場合にはデバイスへの依存度が下がる反面別の漏洩リスクが生まれます。よく検討しましょう。
• RootAccountMfaEnabled
  • AWSアカウントのルートユーザーがコンソールサインインに多要素認証を必要としているかどうかをチェックします。
  • 例外なく必須です。
• S3AccountLevelPublicAccessBlocks
  • 必要なパブリックアクセスブロックの設定がアカウントレベルから設定されているかどうかをチェックします。アカウントレベルからパブリックアクセスブロック設定が設定されていない場合、ルールはNON\_COMPLIANTとなります。
  • S3のパブリックアクセスブロックはS3全体と、S3バケット個別で適用できる一番外側に近いアクセス保護の機能です
  • 一律で公開を防止することもできますが、すべてのアカウントでそのような運用ができないとは思います
  • 多数のAWSアカウントを管理していて、それらに少しずつ公開コンテンツがある場合には管理が大変になってきます
  • 公開コンテンツがある場合にはある程度集約するアカウントに持ってきて管理することも検討しましょう。
  • またS3上のコンテンツの管理にはMacieを利用することも検討しましょう。
• S3BucketLoggingEnabled
  • S3バケットのロギングが有効になっているかどうかをチェックします。
  • アクセスのあるS3バケットの場合はロギングを有効化し、トラッキングできるようにしたほうがいいでしょう。
• S3BucketPolicyGranteeCheck
  • Amazon S3バケットによって付与されたアクセスが、提供するAWSプリンシパル、フェデレートされたユーザー、サービスプリンシパル、IPアドレス、またはVPCのいずれかに制限されているかどうかをチェックします。バケットポリシーが存在しない場合、ルールはCOMPLIANTです。
  • S3へ別の場所からアクセスを許可する場合には適切に絞りましょう。
  • 記述されている要素で制約をかけることが可能です
• S3BucketPublicReadProhibited
  • Amazon S3バケットがパブリックリードアクセスを許可していないことをチェックします。ルールは、パブリックアクセスのブロック設定、バケットポリシー、およびバケットアクセス制御リスト (ACL) をチェックします。
  • 基本的には活用していくといいです。
  • S3を直接外部に公開することはよくありません。
  • 例えば静的ホスティングを行うのであれば、代わりに前段にCloudFrontを挟んでOAI機能で提供しましょう。よく分かる解説
  • またIAM Access Analyzerの機能を利用することにより外部公開の設定がされているリソース一覧を確認することができます。アセスメントにはこちらを活用しましょう。
• S3BucketServerSideEncryptionEnabled
  • Amazon S3 バケットが S3 デフォルトの暗号化を有効にしているか、または S3 バケットポリシーでサーバー側の暗号化なしで put-object リクエストを明示的に拒否しているかをチェックします。
  • ストレージの暗号化の問題と同じです
• S3BucketSslRequestsOnly
  • S3バケットにSSL(Secure Socket Layer)の使用を要求するポリシーがあるかどうかをチェックします。
  • 必須でしょう。
• SagemakerNotebookInstanceKmsKeyConfigured
  • Amazon SageMaker ノートブックインスタンスに AWS Key Management Service (KMS) キーが設定されているかどうかをチェックします。Amazon SageMaker ノートブックインスタンスに 'KmsKeyId' が指定されていない場合、ルールは NON\_COMPLIANT となります。
  • ストレージの暗号化の問題と同じです
• SagemakerNotebookNoDirectInternetAccess
  • Amazon SageMaker ノートブック インスタンスでインターネットへの直接アクセスが無効になっているかどうかをチェックします。Amazon SageMakerノートブックインスタンスがインターネットに対応している場合、ルールはNON\_COMPLIANTとなります。
  • 基本的にはプライベートで保護すべきです。
• SecretsmanagerRotationEnabledCheck
  • AWS Secret Managerのシークレットでローテーションが有効になっているかどうかをチェックします。maximumAllowedRotationFrequency パラメータが指定されている場合、シークレットの回転頻度が最大許容頻度と比較されます。
  • Secret ManagerはSSMの機能の一つでセキュアなパラメーターの管理と自動更新が可能です。
  • ローテートできるシークレットはおとなしくまかせましょう。
• VpcDefaultSecurityGroupClosed
  • 任意のAmazon Virtual Private Cloud（VPC）のデフォルトのセキュリティグループが、インバウンドまたはアウトバウンドトラフィックを許可していないかどうかをチェックします。デフォルトのセキュリティグループに 1 つ以上のインバウンドまたはアウトバウンドトラフィックがある場合、このルールは非準拠となります。
  • デフォルトのセキュリティグループは、意図せずEC2などにアタッチしてしまう可能性があります。
  • デフォルトセキュリティグループは最初VPC内すべてのアクセスが許可されているため、これを削除しておく必要があります。
• VpcFlowLogsEnabled
  • Amazon Virtual Private Cloud のフローログが Amazon VPC で検出され、有効になっているかどうかをチェックします。
  • VPCフローログはVPC内のトラフィックについて記録するサービスです。
  • トラフィックの分だけ記録されて課金対象となるため、金額が許容できないことがままあります。
  • 一方でログのレベルはL3/L4レベルのため役立つ場面は限定的です。
  • 他のログをしっかり取りつつ、これも必要か、費用が許容できそうかは検討したほうがいいでしょう
  • また、すべてのトラフィック以外に、Rejectされたトラフィックの記録だけすることも可能なのでそちらも検討しましょう。

まとめ

NIST CSFのConformance Packsのチェック項目をベースに、各種AWSのサービスの特徴やセキュリティ上の留意点などを解説していきました。

かなり網羅的に考えることができたのではないでしょうか？

これを気にConformance PacksやSecurity Hubのコンプライアンスチェックを有効にしたり、自社のAWS運用のポリシーを固めていってはいかがでしょうか？